TITLE OF THE INVENTION 

Delivery Management Method and Device, and Delivery Information 
Service Method 

BACKGROUND OF THE INVENTION 
Technical Fi^ld 

The present invention relates to the delivery of purchased 
products. More specifically, it relates to the delivery of 
products purchased at stores, through mail order, and through 
online shopping. 
De scription of Related Art 

In recent years it has become customary for products to be 
sold not just at stores, but through mail order and through online 
shopping over the Internet. With this growth in mail order and 
online shopping, there has been a corresponding increase in the 
delivery of products by delivery businesses to the purchasers and 
to parties who receive those products as gifts (hereinafter 
referred to collectively as "delivery recipient"). 

However, with such changes in society as more and more 
households comprising only the nuclear family, husband and wife 
both holding jobs, and more people living by themselves as they 
wait longer to get married, there has been an increasing number 
of instances where delivery cannot be made because the intended 
recipient is not at home. When the recipient is not at home, the 
delivery business has to attempt another delivery at a later time; 
the delivery recipient, seeing the notice that delivery was 



attempted, must request the delivery business to make another 
delivery, and must wait at home for that delivery. This imposes 
a burden both on the delivery business and the delivery recipient, 
and is a factor in rising delivery costs. For this reason, 
services have been proposed such that the party requesting 
delivery can specify delivery date and time, to make certain that 
delivery will be made when he or she is at home. 

In addition, Japanese Laid-open Patent Application 10- 
162065 describes art wherein a home delivery business refers to 
recipient schedule information when determining the time and date 
for scheduling a delivery. Japanese Laid-open Patent Application 
10-269447 describes art relating to home delivery of a purchased 
product. By using this technology, a purchaser can select at time 
of purchase of product his or her desired delivery service from 
among a plurality of possible delivery services. 

Furthermore, Japanese Laid-open Patent Application 5- 
165847 describes art for building a not-at-home database and 
making it possible to predict when a delivery recipient will be 
at home based on this database. This not-at-home database is built 
when the delivery recipient/user comes home, finds that a 
delivery has been attempted, sees the attempted delivery notice 
that the delivery business left, calls the delivery business, and 
informs the delivery business of his or her desired date and time 
of delivery. 

While the above-described background technology is 



effective to a certain degree, in that it increases the 
probability that the delivery will be made when the intended 
recipient is at home, it leaves the following problems unsolved. 

First, when a single user has purchased products from a 
plurality of vendors, each vendor may use a different delivery 
business, and even if they do use the same delivery business the 
deliveries will still be made at different times. Thus, there are 
delivery charges for each product, meaning an increase in 
delivery costs. And, for example, because a plurality of delivery 
businesses will come to make delivery, a user will have to respond 
to each delivery, which is bothersome. 

Second, even if a delivery date and time were specified when 
requesting delivery, there are times when a user will want to 
change that delivery date and time because, for example, of a 
change in plans. In such cases, even if the user tries to request 
a change over the phone, there may be times when he or she is unable 
to get through to the delivery business because, for example, the 
offices aren't open, or it is difficult to make the change, or 
the getting the change done requires much time and effort. For 
example, if a user plans to have a plurality of products delivered 
all on the same day off, he or she must get in touch with a 
plurality of delivery businesses. And when sending a gift to 
another person, asking that person beforehand when a good time 
for delivery is and then specifying a delivery date and time not 
only is bothersome, it also diminishes the pleasure of both giving 



and receiving the gift. 

Third, if a user lives with someone else, he or she can have 
that other person receive that delivery in his or her place, but 
it is bothersome to have to ask fellow family members their plans 
each time one schedules a delivery. In the end this can lead to 
a situation where individual family members schedule deliveries 
on their own, and the overall trouble involved in being present 
to receive delivery increases. 

Fourth, there are cases where in spite of the fact that a 
user paid for a product at the time that he or she ordered, because 
a vendor is out of stock for that item or is waiting for a shipment 
of that item, it takes a considerable time for that product to 
reach the user who made the order. The lag between the time of 
order and the time of receipt is a cause of frustration to the 
user who made the order. 
SUMMARY OF THE INVENTION 

It is an object of the present invention to resolve the 
above problems by allowing for efficient delivery, to alleviate 
the burden both to delivery recipients and to delivery 
businesses. 

The present invention makes possible the consolidated 
processing of delivery information that conventionally has been 
processing independently for each vendor or product provider and 
each delivery business. This allows a user to enjoy the benefits 
of a service that allows him or her to know beforehand when a 



product will be delivered, and to designate how he or she will 
receive an article, in accordance with his or her convenience and 
preference. And this allows delivery businesses to enjoy a 
service that makes it possible to deliver at the same time 
products that have conventionally been delivered separately, 
despite the fact that they all had the same delivery recipient, 
leading to increased overall efficiency of the delivery 
business 's delivery work. 

Thus, in order to solve the above-described problems, the 
present invention provides a method for managing delivery of 
products that have been ordered, wherein: 

A: an application for delivery of the product is received 
from a provider of the product; 

B: an application ID is assigned to the application; 
C: the delivery recipient of the product is notified of the 
application ID and is prompted to designate delivery terms; 

D: the delivery recipient is presented with a list of 
products scheduled to be delivered to the delivery recipient and 
the application IDs therefor; 

E: designation of delivery terms for the application 
specified by the application ID is accepted from the delivery 
recipient after order of the product; and 

F: request for delivery is made by notifying a 
predetermined delivery business of the products corresponding to 
application IDs for which the same delivery terms have been 



designated, of the designated delivery terms, and of the delivery 
recipient. 

For example, let us consider a case where a user A makes 
an online purchase of a product Q from a company X and designates 
oneself as a recipient. Company X makes an application with a 
predetermined management server for delivery to user A. The 
management server, upon receiving this application, sends to user 
A an email with the URL of a web page with a form for inputting 
delivery terms, so that user A can designate those delivery terms. 

When user A accesses that web page, a list of products 
scheduled to be delivered to him or her is displayed, and he or 
she can input the delivery terms for each product. Delivery terms 
herein are such matters as delivery date and time, delivery place, 
type of delivery service, delivery business, etc. This web page 
may also give notification of whether the product scheduled for 
delivery is in stock or not. This web page may also give 
notification of the state of delivery for products for which 
delivery terms have already been specified. 

A delivery business is notified of the delivery terms, and 
the delivery business delivers the product to the delivery 
recipient in accordance with the delivery terms. 

By using this method, a delivery recipient can designate 
whatever time is convenient for receipt of the package, and 
furthermore can receive a plurality of packages at the same time. 
Of course delivery terms can be changed from product to product. 



For a delivery business, because it can make combined delivery 
of products, this will lead to a reduction in costs and time spent. 
Furthermore, the party providing the management server can 
realize a profit. For example, a delivery business can have part 
of the cost reductions reflected in reduced delivery charges, and 
pay the remainder to the party providing the management server. 

A second aspect of the present invention provides a 
delivery management method in accordance with the first- 
mentioned aspect. In the method, formation of a group and 
designation of group members is accepted from the delivery 
recipient, and when a delivery recipient is notified of the 
product and application ID, notification is also given of a list 
of products scheduled for delivery to other members of the group 
to which the delivery recipient belongs and the application IDs 
therefor. 

Let us suppose that the members of a single household form 
a group. When any member of the group wishes to see the list of 
products scheduled for delivery, that member will be able to see 
at the same time a list of products scheduled for delivery to other 
members. Thus, if another member of the group has already 
designated delivery terms, by designating the same delivery terms, 
the family can have the products all delivered at once. 

A third aspect of the present invention provides a delivery 
management method according to the first-mentioned aspect. In 
the method, when first delivery terms have been designated for 



a first product scheduled to be delivered to the delivery 
recipient, and prior to delivery of the first product, delivery 
terms are designated for another, second product, the delivery 
terms that were set for the first product are changed to the 
delivery terms set for the second product. 

Let us suppose that a user A has designated "7/23/2000, 
morning," for delivery of a product Q. Thereafter, user A 
purchases another product, and designates delivery for 
"7/25/2000, evening." Usually it is reasonable to assume that the 
terms that were designated later are more convenient for the user. 
Thus if product Q has not yet been delivered, the delivery terms 
for product Q are also set as "7/25/2000, evening." 

A fourth aspect of the present invention provides a 
delivery management method according to the first-mentioned 
aspect. In the method, when the recipient is the party that 
ordered the product, notification to the effect that the product 
specified by the application ID has been purchased is given to 
the provider of the product after the delivery terms 
corresponding to the application specified by the application ID 
have been designated. 

Settlement of payment is conducted not at the time the 
product is ordered, but after delivery terms have been designated. 
For the user, this brings about an improvement of such situations 
where he or she does not receive the product even though a charge 
has been made to a credit card, and it also shortens the lag 



between the time receipt of the product and paying for the 
product. 

A fifth aspect of the present invention provides a delivery 
management method according to the first-mentioned aspect, in 
the method, when the delivery recipient is the party that ordered 
the product, the provider of the product is notified that the 
product specified by the application ID has been purchased, the 
notification occurring after the delivery terms for the 
application specified by the application ID have been designated. 

A sixth aspect of the present invention provides a delivery 
management method according to the first-mentioned aspect, in 
the method, when the delivery recipient is the party that ordered 
the product, the provider of the product is notified that the 
order for the product specified by the application ID has been 
cancelled, the notification occurring by means of the application 
specified by the application being cancelled. 

When a user discovers a better product after having made 
an order, the user can cancel that order. 

A seventh aspect of the present invention provides a 
delivery management device comprising accepting means, assigning 
means, prompting means, providing means, designating means and 
requesting means. 

Accepting means accepts application for delivery of a 
product. Assigning means assigns an application ID to the 
application. Prompting means notifies the product delivery 



recipient of the application ID and prompts the delivery- 
recipient to designate delivery terms. Providing means provides 
the delivery recipient with a list of products scheduled to be 
delivered to the delivery recipient and the application IDs 
therefor. Designating means receives from the delivery recipient 
designation of delivery terms corresponding to the application 
specified by the application ID after the product has been ordered. 
Requesting means requests delivery by notifying a predetermined 
delivery business of products corresponding to application IDs 
for which the same delivery terms have been designated, of the 
designated delivery terms, and of the delivery recipient. 

This device of the present invention is equivalent to a 
server that executes the above-described method. 

An eighth aspect of the present invention provides a 
computer-readable recording medium on which is recorded a program 
for executing the delivery information service method used in a 
delivery information service device wherein a plurality of user 
terminals, a plurality of transport business terminals and a 
plurality of vendor terminals are interconnected over a network. 
This program executes the following steps A through E: 

A: processing for reception of product delivery request 
information sent from a vendor terminal or user terminal; 

B: processing for storage of the received delivery request 
information in a delivery request information storage unit; 

C: processing for extraction from the delivery request 
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information storage unit of delivery request information for 
deliveries that have not yet been made, the delivery recipient 
being the same as the delivery recipient in the received delivery 
request information; 

D: processing for acquiring a notification address of the 
delivery recipient from a correspondence table of notification 
addresses that are held having been corresponded beforehand with 
delivery recipients, and for sending notification to the 
notification address of the delivery recipient of the received 
delivery request information, of the extracted delivery-pending 
delivery request information, and of information prompting the 
input of desired delivery terms, such as desired date and time 
of delivery; and 

E: processing for transmission to a transport business 
terminal of information giving instruction for delivery of the 
article for delivery to the delivery recipient in accordance with 
the desired delivery terms sent from the delivery recipient. 

A ninth aspect of the present invention provides a delivery 
information service method comprising steps of: 

A: a delivery request for an article is received, the 
received delivery request is stored in a storage device, and the 
storage device is searched and delivery requests for pending 
deliveries with the same delivery recipient as the delivery 
recipient of the delivery request; 

B: an address table wherein delivery recipients and 
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notification addresses have been corresponded beforehand is 
referred to and the notification address of the delivery 
recipient is extracted; 

C: notification is given to the delivery recipient 
notification address of the delivery request and of the extracted 
delivery-pending delivery request and the user is prompted to 
input desired delivery terms such as date and time when receipt 
of the article scheduled for delivery is possible; and 

D: based on the desired delivery terms given in response, 
instructions are made for delivery to the delivery recipient of 
the article scheduled for delivery, the instructions being given 
to a delivery business that has been designated by the desired 
conditions or that matches the desired conditions. 
BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an overall block diagram of the delivery 
management system relating to the first embodiment; 

FIG. 2 is a conceptual diagram for explaining the 
information stored in the delivery information database in the 
system of FIG. 1; 

FIG. 3 is a conceptual diagram for explaining information 
stored in the user database in the system of FIG. 1; 

FIG. 4 is a diagram showing the flow of delivery application 
acceptance processing; 

FIG. 5 is a diagram for explaining product for delivery 
information; 
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FIG. 6A is a diagram explaining the flow of stock condition 
processing; 

FIG. 6B is a diagram explaining the flow of delivery condition 
processing; 

FIG. 7 is a diagram explaining the flow of product for delivery 
list notification processing; 

FIG. 8 is a diagram explaining the flow of delivery terms 
designation processing; 

FIG. 9 is an example of a screen for the vendor to input delivery 
application; 

FIG. 10 is an example of notification to a delivery recipient 
of delivery application; 

FIG. 11 is an example of a screen displaying a product for 
delivery list; 

FIG. 12 is an example of inputted delivery terms; 

FIG. 13 is an example of notification to a delivery business 
of a delivery request; 

FIG. 14 is an overall block diagram of the delivery management 
system relating to the second embodiment; 

FIG. 15 is a conceptual diagram for explaining the information 
stored in the user database in the system of FIG. 14; 

FIG. 16 is a diagram explaining the flow of product for delivery 
list notification processing in the system of FIG. 14; 

FIG. 17 is an example of a screen displaying a product for 
delivery list in the system of FIG. 14; 



FIG. 18 is an example of inputted delivery terms in the system 
of FIG. 14; 

FIG. 19 is an overall block diagram of the delivery management 
system relating to the third embodiment; 

FIG. 20 is a diagram explaining the flow of delivery terms 
designation processing in the system of FIG. 19; 

FIG. 21 is a diagram explaining the flow of cancellation 
processing in the system of FIG. 19; 

FIG. 22 is an example of a delivery terms and cancellation 
designation screen in the system of FIG. 19; 

FIG. 23 is an overall block diagram of the delivery management 
system relating to the fourth embodiment; 

FIG. 24 Is a diagram explaining the flow of product for delivery 
list notification; 

FIG. 25 is a conceptual diagram of product for delivery 
information in the system of FIG. 23; 

FIG. 2 6 is a diagram showing the flow of delivery terms 
designation processing in the system of FIG. 23; 

FIG. 27 is an example of an inputted application for delivery 
to a delivery recipient in the system of FIG. 23; and 

FIG. 28 is an example of inputted delivery terms in the system 
of FIG. 23. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Overall Configuration 

The delivery management system relating to the present 



invention makes possible the combined delivery of products for 
delivery to the same delivery recipient. A user can schedule a 
delivery after an application for delivery has been made, and can 
select a preferred home-delivery business to make the delivery. 
5 Also, combined delivery can be made of products for delivery to 
the same household. When a gift is to be sent to another person, 
the recipient of the gift can schedule delivery for a date and 
time convenient to him or her after the gift giver has purchased 
the gift and made an application for delivery. This eliminates 
10 cases where the pleasures of gift-giving and receiving are 

diminished because recipient of the gift learns beforehand that 
a gift is to be made. 
First Embodiment 

(1) Configuration of Delivery Management System 
15 FIG. 1 is an overall block diagram of the delivery 

management system relating to a first embodiment of the present 
invention. The delivery management system in the present 
embodiment comprises a vendor client 1, a delivery business 
client 2, a delivery recipient client 3 and a management server 
20 4 interconnected via a network (not shown in the figure) governed 
by HTTP. Vendor herein means the party providing products, and 
includes the manufacturer of a product. 

The management server 4 has an HTTP server 5 and an email 
server 6. The HTTP server 5 and the email server 6 do not have 
25 to be on the same computer, and may operate on independent 
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computers. The HTTP server 5 functions as the front end, receiving 
connections from clients. 

Specifically, the HTTP server 5 activates in response to 
the type of request a CGI program group represented by a delivery 
5 application acceptance unit 51, a delivery terms acceptance unit 
52, a product for delivery list display unit 53, a stock 
conditions reception unit 54 and a delivery terms reception unit 
55. Using these CGI programs, the HTTP server 5 also manages a 
delivery information database 8 in which delivery information is 

10 stored and a user database 7 in which personal information for 
delivery recipients is stored. The HTTP server 5 also activates 
CGI programs represented by a delivery application transmission 
unit 56 and a delivery request transmission unit 57- These 
programs access the email server 6 and send email messages to the 

15 delivery business client 2 and the delivery recipient client 3. 

Each client, that is, the vendor client 1, the delivery 
business client 2 and the delivery recipient client 3, are 
computers with functions for accessing the management server 4. 
Personal computers and cell phones having WW browser functions 

20 are examples of such clients. These clients also have email 
receipt and transmission functions. 
(2) Database 

(2-1) Delivery Information Database 

FIG. 2 is a conceptual drawing showing information stored 
25 in the delivery information database 8. Herein, "delivery 



recipient ID" is the ID allocated to delivery recipients in this 
system. In the "requester" column the names of parties requested 
delivered are entered. The delivery recipient and the requester 
may be the same person or they may be different. In the present 
5 embodiment, in order to facilitate explanation, an explanation 
will be given for a case where they are the same. The "vendor" 
is bhe party that makes the application for delivery, i.e., the 
shipper of the product to be delivered. In the "item for delivery" 
column the items products for delivery are entered. 

10 This database also has fields for "delivery date," 

"delivery place," and "delivery business." These fields are left 
blank until the delivery recipient makes designations for 
delivery terms . 

The "application ID" is identification information that 

15 the system has allocated to one set of the above information. The 
"stock conditions" and "delivery terms" are input by the product 
vendor and delivery business, respectively. 
(2-2) I7ser Database 

FIG. 3 is a conceptual diagram showing information stored 

20 in the user database 7. Stored in this database are "user ID," 
and the "name," "delivery place, " "address," "email address," and 
"telephone number" of the delivery recipients. A plurality of 
delivery places can be registered for each user ID, with addresses 
and telephone numbers designated for each delivery place. Users 

25 who are product delivery recipients or requesters are registered 



as users in the user database 7 prior to their use of this system. 

(3) Processing Flow 

(3-1) Delivery Acceptance Reception 

FIG. 4 is diagram explaining the flow of delivery 
5 acceptance processing conducted by the HTTP server 5. 

When a vendor wishes to make a request for delivery to a 
delivery business, it first accesses the HTTP server 5 with a WWW 
browser and applies for a delivery (#1) . This application is made 
by inputting predetermined information relating to the product 
10 to be delivered (refer to FIG. 9 below) . 

The HTTP server 5 upon receipt of the input information, 
activates the CGI program of the delivery application acceptance 
unit 51 (#2). 

The delivery application acceptance unit 51, based on the 
15 input information, creates product to be delivered information 
as shown in FIG. 5 and writes product to be delivered information 
to the delivery information database 8 (#3). As shown in the 
figure, product to be delivered information contains delivery 
recipient user ID (hereinafter "delivery recipient ID"), 
20 requester user ID (hereinafter "requester ID"), deliverer, 
product for delivery, and application ID. 

The delivery application acceptance unit 51 calls the 
delivery application transmission unit 56 CGI program and 
provides it with product for delivery information (#4). The 
25 delivery application transmission unit 56 accesses the user 



database 7 and searches for the delivery recipient email address 
using the delivery recipient ID as the key (#5). 

The delivery application transmission unit 56 accesses the 
email server 6 and sends delivery notification to the delivery 
recipient email address (#6, #7). This notification contains the 
URL for a web page on which is posted predetermined information 
relating to the delivery. An email message stating that a product 
delivery application has been made is sent to the delivery 
recipient (refer to FIG. 10 below). 

(3-2) Registration Processing for Stock Conditions and Delivery 
terms 

FIG. 6A is a diagram explaining the flow of stock condition 
registration processing conducted by the HTTP server 5 and FIG. 
6B is a diagram explaining the flow of delivery condition 
registration processing conducted by the HTTP server 5. In these 
processings, vendors and delivery businesses register stock 
conditions and delivery terms, respectively, in the delivery 
information database 8. Stock condition registration processing 
and delivery condition registration processing are the same 
except for the fact that the registered information pertains 
either to stock conditions or delivery terms; thus an explanation 
will be given below just of the stock conditions. 

When the vendor client 1 accesses the management server 4, 
authentication processing is conducted (#11, #21). When 
authentication is made, the vendor client 1 sends stock 



conditions (#12, #22). Application ID is included in these stock 
conditions. The HTTP server 5, upon receipt thereof, activates 
the stock conditions reception unit 54 CGI program (#13, #23). 
The stock conditions reception unit 54 accesses the delivery 
5 information database 8, and with the application ID as the key, 
updates the stock conditions for the relevant product (#14, #24) . 
(3-3) Notification of Product for Delivery List Processing 

FIG. 7 is a diagram explaining the flow of notification of 
product for delivery list processing conducted by the HTTP server 

10 5. When a delivery recipient uses a WWW browser to access the URL 
for which notification was given by email (#31), the HTTP server 
5 authenticates the delivery recipient. When the delivery 
recipient is authenticated, the product for delivery list display 
unit 53 CGI program is activated (#32). 

15 The product for delivery list display unit 53 accesses the 

delivery information database 8, and using the delivery recipient 
ID as a key, acquires a list of products for delivery scheduled 
to be delivered to the delivery recipient (#33) . The product for 
delivery list display unit 53 then formats the acquired 

20 information in HTML file format (#34) and provides this to the 
delivery recipient (#35) . At the delivery recipient client 3, the 
WWW browser displays a product for delivery list form (see FIG. 
11 below). Designation of delivery terms, to be discussed below, 
can be input into this product for delivery list form (refer to 

25 FIG. 12 below) . 



(3-4) Delivery Terms Designation Processing 

FIG. 8 is a diagram showing the flow of delivery terms 
designation processing conducted by the HTTP server 5. 

When a delivery recipient inputs delivery terms into the 
form and sends this to the HTTP server 5 (#41), the HTTP server 
5 calls the delivery terms acceptance unit 52 CGI program (#42) . 
These delivery terms are delivery date, delivery place, delivery 
business, etc.; they correspond to items in the delivery 
information database 8. The designation of delivery terms may be 
made at a point in time when the delivery recipient knows for 
certain what date and time, for example, are convenient, and does 
not have to be made immediately after receipt of delivery 
application notification, or immediately after viewing the 
products for delivery list. 

The delivery terms acceptance unit 52 accesses the delivery 
information database 8 and writes the received delivery terms 
therein (#43). The delivery terms acceptance unit 52 also calls 
the delivery request transmission unit 57 program and provides 
it with the delivery terms (#44). The delivery request 
transmission unit 57 accesses the user database 7, and using the 
delivery recipient ID as a key, acquires delivery recipient 
information such as the delivery recipient's name, address and 
phone number (#45). Next, the delivery request transmission unit 
57 accesses the email server 6 and sends to the delivery business 
client 2 an email message requesting delivery that contains the 



delivery terms and the delivery recipient information (#46). 

It should be noted that this designation of delivery terms 
can be partially automated. For example^ let us suppose that 
delivery terms X have been designated for a certain product A; 
then, prior to delivery of this product A, there is a delivery 
request for another product B. Because it can be said that if the 
delivery terms X are followed it is guaranteed that the delivery 
recipient will be able to receive the delivery, the system can 
be programmed so that the delivery terms set for the product A 
are automatically set for the product B without asking the 
delivery recipient to set delivery terms. On such an occasion, 
it is fine to notify the user that an additional product will be 
delivered on the scheduled delivery day. As long as there is an 
item that has not yet been delivered, arrangements will be 
automatically made so that any new item for delivery will be 
delivered along with it. This means that the user does not have 
to go through the trouble of designated delivery terms every time 
there is a new product for delivery, and the delivery business 
has to make fewer individual deliveries due to such factors as 
delays in response from the delivery recipient, meaning that it 
will be able to make deliveries in which the products to be 
delivered are combined to the greatest extent possible, leading 
to increased efficiency. Also conceivable is the opposite case, 
where the delivery terms y for product B set afterwards reflect 
the delivery recipient user's most up-to-date desired terms. In 

- 22- 



such cases, the system can be programmed so that the delivery 
terms X for not yet delivered product A are automatically changed 
to reflect the delivery terras for the newly ordered product B. 
Or the system may be programmed so that when delivery terms have 
5 been designated for product B, the user is notified that there 
is a delivery-pending product for which differing delivery terms 
have been designated, and change of the delivery terms is 
conducted only after the user confirms that it is all right to 
do so. Thus when a user has changes in plans after having 

10 designated delivery terms, those changes are automatically 

reflected in the delivery terms, the user does not have to bother 
changing the delivery terms, and the delivery business can reduce 
losses due to changes in the plans of the delivery recipient user. 
With the above processing, after a product has been ordered, 

15 a user can designate a date and time for delivery according to 
changes in his or her schedule and have a delivery made 
accordingly. Moreover, because a delivery recipient can receive 
a plurality of packages at once, a delivery business will benefit 
from a reduction in the time and effort involved in delivery and 

20 can therefore lower its delivery charges, meaning that both the 
charges for delivery and the time and effort spent in receiving 
a delivery will be reduced. In addition, the provider of the 
management server 4 can realize a profit by collecting a portion 
of the cost savings as a handling fee. 

25 (4) Screen Examples 



FIG. 9 is an example of an input screen for the vendor to 
input a delivery application. In this example, the screen is 
posted on a web page. The delivery recipient ID and the requester 
ID may be the same or they may be different. When the product is 
5 a gift, for example, these IDs will be different. 

FIG. 10 is an example of a notification to a delivery 
recipient of a delivery application. The URL of the web page for 
inputting delivery terms is given here. In addition, it is also 
preferable to include the product for delivery and the name of 
10 the vendor. 

FIG. 11 is a display example of a products for delivery list. 
In this example, this screen is provided on a web page. Delivery 
date, delivery place and delivery business can be set or changed 
on this screen. This figure shows a case where the delivery terms 
15 have not yet been designated. 

FIG. 12 is an example showing delivery terms inputted. It 
is convenient for the user if a pull-down menu displays possible 
choices when inputting delivery terms, for example, delivery 
place and delivery business. On this form, not only can items that 
20 have not yet been set be set, but items that have already been 
set can be changed. 

FIG. 13 is an example of a notification to a delivery 
business of a delivery request. Delivery date and time have been 
given as delivery terms, and name, address and phone number have 
25 been given as delivery recipient information. Also, the product 



to be delivered and the vendor name have also been given. 
Second Plmbodiment 

(1) Configuration of Delivery Management System 

FIG. 14 is a block diagram showing the overall constitution 
5 of the delivery management system according to a second 

embodiment. In this system, a delivery recipient group management 
unit 58 has been added to the constitution of the delivery 
management system according to the first embodiment. Delivery 
recipients are groups formed beforehand in units, for example, 
10 of households. The delivery recipient group management unit 58 
receives registration of members of a group from delivery 
recipients and registers these in the user database 7. 

As shown in FIG. 15, this user database 7 differs from the 
user database 7 in the first embodiment in that information for 
15 "group" is stored. The other stored inforxuation is the same as 
above . 

Other constituent elements having the same designator as 
in FIG. 1 have the same function as the corresponding element in 
the first embodiment. 
20 (1) Processing Flow 

In the present embodiment, the processing flow for delivery 
acceptance processing, stock condition/delivery condition 
registration processing and delivery terms designation 
processing is the same as in the first embodiment. In addition 
25 to these processings, this system performs the following 



processing: 

Products for delivery list notification processing 

FIG. 16 is a flow chart showing the flow of products for 
delivery list notification processing. 

When a delivery recipient uses a WWW browser to access the 
management server 4 (#51), delivery recipient authentication 
based on delivery recipient ID is conducted. Upon authentication, 
the product for delivery list display unit 53 CGI program is 
activated, and it is provided with the delivery recipient ID (#52 ) . 
The product for delivery list display unit 53 accesses the user 
database 7, and with the delivery recipient ID as key, acquires 
the delivery recipient ID of other members of the group to which 
the accessing delivery recipient belongs (#53). 

Next, the product for delivery list display unit 53 
accesses the delivery information database 8, and using the group 
members' delivery recipient IDs as keys, acquires a list of 
scheduled products for delivery scheduled to be delivered to a 
delivery recipient belonging to that group (#54). This is 
formatted in HTML file format (#55), and sent to the accessing 
delivery recipient (#56). 
(2) Screen Example 

FIG. 17 is a screen example showing a product for delivery 
list. In addition to products for delivery to the accessing 
delivery recipient, a list of products for delivery scheduled to 
be delivered to members of the group to which the accessing 



delivery recipient belongs is displayed 

FIG. 18 show a delivery terms input example. As with the 
first embodiment, the delivery recipient uses this to designate 
such delivery terms as delivery date, delivery date, delivery 
5 business, etc. and the delivery terms are notified to the delivery 
business. In this figure, the items that have not yet been set, 
that is, delivery date, delivery place, and delivery business, 
can be changed only by the delivery recipient user him or herself. 
In principle, the items set for other group members cannot be 

10 changed. But the system may be set so that the items of other group 
members can be changed according to need. 

As described above, in the present embodiment, among user 
groups such as families, a plurality of deliveries can be combined 
into one, making possible a further improvement in delivery 

15 efficiency. 

Third Kmhodiment 

(1) Configuration of Delivery Management System 

FIG. 19 is a block diagram showing the overall constitution 
of the delivery management system according to a third embodiment 

20 of the present invention. This system comprises the delivery 
management system according to the first embodiment, with the 
addition of a cancellation acceptance unit 59 and a purchase right 
control unit 510. Other constituent elements having the same 
designator as in FIG. 1 have the same function as the 

25 corresponding element in the first embodiment. 



The cancellation acceptance unit 59 accepts cancellation 
of orders for products . 

The purchase right control unit 510 notifies the vendor 
client 1, when delivery terms have been designated for a delivery 
application, that a product specified by the ID for that 
application has been purchased. 
(2) Processing Flow 

In the present embodiment, the processing flow for delivery 
acceptance processing, stock condition/delivery condition 
registration processing and products for delivery list 
notification processing is the same as in the first embodiment. 
In addition to these processings, this system performs delivery 
terms designation processing and cancellation processing, as 
described below. 

(2-1) Delivery Terms Designation Processing 

FIG. 20 is a diagram showing the flow of delivery terms 
designation processing performed by the HTTP server 5. The 
processing for writing designation of delivery terms in the 
delivery information database 8 (#61 to #63) and sending delivery 
recipient information and sending said designation to the 
delivery business client 2 (#64 to #67) is the same as in the first 
embodiment . 

The delivery terms acceptance unit 52 further calls the 
purchase right control unit 51 CGI program, and provides it with 
purchase instructions (#68). These instructions include 
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application ID and product name for specifying the product for 

which delivery terms have been set. 

The purchase right control unit 510 accesses the email 

server 6 and sends the vendor client 1 notification of the 
5 purchase instructions, including application ID and product name 

(#69, #610). The vendor, upon receipt of this notification, 

performs settlement processing for invoicing the delivery 

recipient for the charges for the product. 

This processing allows the time lag between the time of 
10 payment for the ordered product and time of delivery of that 

product to be shortened. Also, the party that ordered the product 

can put off paying for the product until the product is actually 

available for delivery. 

(2-2) Cancellation Processing 
15 FIG. 21 is a diagram showing the flow of cancellation 

processing performed by the HTTP server 5. 

In this example, an application for delivery can be 

cancelled using the form for inputting delivery terms (see FIG. 

22 below). The HTTP server 5 receives a cancellation (#71), and 
20 calls the cancellation acceptance unit 59 CGI program (#72). The 

cancellation acceptance unit 59 accesses the delivery 

information database 8 and deletes the entry for the cancelled 

application (#73). The HTTP server 5 calls the purchase right 

control unit 510 CGI program and provides it with the application 
25 cancellation instructions (#74). These instructions contain the 



ID for the cancelled application. The purchase right control unit 
510 accesses the email server 6, and sends to the vendor client 
1 notification that the order for the product relating to the 
application has been cancelled (#75, #76). 
5 With this processing, if the party that has made the order 

finds a better product before making payment, that party can make 
a change with a minimum of cost and effort. The vendor may charge 
the delivery recipient a cancellation penalty, in the form of a 
cancellation fee. 
10 (3) Screen Example 

FIG. 22 shows an example of a screen using which a delivery 
recipient designates delivery terms and cancellation. By 
checking the "cancel" field, a delivery recipient can cancel the 
purchase of a product. 
15 Fourth Embodiment 

(1) Configuration of Delivery Management System 

FIG. 23 is a block diagram showing the overall constitution 
of the delivery management system according to a fourth 
embodiment of the present invention. This system comprises the 
20 delivery management system according to the first embodiment, 
with the addition of a settlement unit 511 and a delivery business 
database 9. In addition, the delivery information database 8 is 
provided with a delivery charge payer field (not shown) . The user 
database 7 is provided with a credit card information field (not 
25 shown) . Other constituent elements having the same designator as 
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in FIG. 1 have the same function as the corresponding element in 
the first embodiment. 

The delivery business database 9 is shared by this system 
and delivery businesses, and can be updated by delivery 
5 businesses. There may be a plurality of databases, one for each 
delivery business, or this database may be on servers managed by 
delivery businesses. This database stores the delivery schedule 
of the delivery business, and rate data according to delivery 
region and type of delivery service. 

10 The settlement unit 511 performs settlement processing for 

invoicing the party that will pay the charges. For settlement 
processing, it is good to store credit card information 
beforehand in the user database 7. 
(1) Processing Flow 

15 As with the first embodiment, this system performs stock 

condition and delivery condition registration processing. In 
addition to these processings, the following processings are 
performed in this system. 
(2-1) Delivery Acceptance Processing 

20 With the exception of the following points, the HTTP server 

5 performs delivery acceptance processing in the same manner as 
in the first embodiment (not shown in figure). The vendor client 
1 accesses the email server 6 and sends a delivery application 
(see FIG. 27 below). In addition to the contents as described in 

25 the first embodiment, this application allows entry of which 



party will pay for the charges, in the event that the delivery 
recipient ID and the requester ID are different. 

The delivery application acceptance unit 51 creates 
delivery product information from the input contents it has 
5 received. FIG. 25 is a conceptual diagram of the delivery product 
information. In addition to delivery recipient ID, requester ID, 
vendor, and product for delivery application ID, the charge payer 
is also included. The delivery application acceptance unit 51 
accesses the delivery information database 8 and writes this 
10 product for delivery information therein. 

(2-2) Product for Delivery List Notification Processing 

FIG. 24 is a diagram showing the flow of product for 
delivery list notification processing performed by the HTTP 
server 5 . 

15 When a delivery recipient accesses management server 4 

using a WWW browser (#81), the HTTP server 5 performs 
authentication based on delivery recipient ID and the like. Upon 
authentication, the product for delivery list display unit 53 CGI 
program is activated (#82) . The product for delivery list display 

20 unit 53 first accesses the delivery information database 8, and 
using delivery recipient ID as the key, acquires a list of 
products for delivery to the accessing delivery recipient as well 
as the delivery information therefor (#83). 

Next, the product for delivery list display unit 53, using 

25 delivery information as key, searches the delivery business 



database 9. For example, using delivery place and delivery date 
as keys, it searches the schedule of the delivery business. Then 
it acquires a list of delivery businesses that can deliver the 
product for delivery as well as the charges for that delivery 
5 (#84). 

The product for delivery list display unit 53 formats the 
acquired information in HTML file format and sends this in an 
email message to the delivery recipient (#85, #86). A form that 
includes delivery charges and delivery services is displayed at 

10 the delivery recipient client 3. 

(2-2) Delivery Terms Designation Processing 

FIG. 26 is a drawing showing the flow of delivery terms 
designation processing performed by the HTTP server 5. 

The HTTP server 5 receives the designation of delivery 

15 terms inputted into the above-described form (#91) and calls the 
delivery terms acceptance unit 52 CGI program (#92) . The delivery 
terms acceptance unit 52, as in the first embodiment, writes the 
delivery terms (#93) and gives notification of the delivery terms 
(#94). Thus the delivery recipient information is sent as email 

20 to the delivery business client 2 (#95, #96, #97). 

Next, the delivery terms acceptance unit 52 provides 
settlement instructions to the settlement unit 511 (#98). In 
other words, instructions are given to the settlement unit 511 
to assess charges against the party to bear the charges. The 

25 settlement unit 511 accesses the user database 7 and, using 



delivery recipient ID as the key if the delivery recipient is to 
bear the charges, or requester ID as the key if the requester is 
to bear the charges, acquires the credit card number to be used 
for settling the charges (#99). The settlement unit 511, in 
5 addition to performing settlement processing, accesses the email 
server 6 (#100) and sends an email message giving notification 
of the settlement to the client of the appropriate party (#101) . 

With the above processing, instead of the conventional 
uniform charges, charges can be collected that accurately reflect 

10 delivery terms. It also becomes possible to decide on delivery 
terms such that the delivery recipient schedule and the schedule 
of the delivery business match. A delivery business may implement 
a service, for example, that offers a discount when all the 
packages can be loaded into a single truck. 

15 (2) Screen Examples 

FIG. 27 is an example of an input screen for a vendor to 
apply for delivery. Unlike the first embodiment, there is a field 
for input of charge payer. 

FIG. 28 is an example of inputted delivery terms displayed 

20 at the delivery recipient client 3 . Only those delivery 

businesses that can make delivery fulfilling such delivery terms 
as delivery date and desired type of service are displayed in a 
pull-down menu. Types of service include, for example, special 
rush delivery, over-sized packages, and delivery in refrigerated 

25 trucks. In addition, charges are displayed according to the 



selected delivery terms. The total current charges that the 
delivery recipient is to pay are also displayed. The system may 
be programmed so that when the delivery recipient and the 
requester are different, and the requester is to pay the charges, 
5 the charges are displayed but not included in the total, or the 
charges are not displayed. 
Other Embodiments 

(A) In the above embodiments, CGI programs are used, but 
other technology that performs similar functions may be used, 

10 such as Java servlets. Also, communication means other than email 
may be used for performing notification of delivery application 
and delivery requests. 

(B) The above embodiments may be combined as needed. 

(C) A recording medium on which is recorded a program for 
15 executing the above-described methods of the present invention 

is included in the present invention. Possible types of recording 
media include computer-readable floppy diskettes, hard disks, 
semiconductor memory, CD-ROMs, DVDs, magneto-optical disks, etc. 
By using the present invention a user can know, before a 

20 product actually arrives, when a product scheduled for delivery 
will be delivered, and can receive deliveries from a plurality 
of delivery businesses around the same time or the delivery of 
a plurality of products at once, reducing both delivery charges 
and the effort involved in receiving deliveries. Families and 

25 other groups can also receive deliveries from a plurality of 



delivery businesses around the same time or the delivery of a 
plurality of products at once. Moreover, even after applying for 
delivery, a delivery recipient can make designations for delivery 
terms that match changes in his or her schedule. 
5 While only selected embodiments have been chosen to 

illustrate the present invention, to those skilled in the art it 
will be apparent from this disclosure that various changes and 
modifications can be made herein without departing from the scope 
of the invention as defined in the appended claims. Furthermore, 
10 the foregoing description of the embodiments set forth in the 
present invention is provided for illustration only, and not for 
the purpose of limiting the invention as defined by the appended 
claims and their equivalents. 

15 
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